Networks exist in many different forms. A network can be considered to be defined by its underlying topology and any associated policies imposed on use of that topology. The same combination of components can often be implemented in many different ways, each implementation potentially resulting in networks offering vastly different capacities, redundancy etc.
Capacity management is often used to describe techniques and actions used by network administrators to plan for network growth, expected or unexpected topology failures and also to explore possible network optimisations to ensure that the network will meet projected needs.
Network topologies can be defined at many different levels of granularity and this has a knock-on effect on capacity management. If a network topology is defined too generically, insufficient information is typically available to enable a network to be analysed and optimised. However, defining the potentially tens of thousands of nodes, links, interrelationships, constraints and other factors that may make up (or be used to make up) a network topology can be exceptionally costly and time consuming any may then present too much information for an analysis or optimisation system to sensibly utilise and produce a result in an acceptable timeframe.
Tools and systems are available at varying levels of complexity, price and performance. At their most simplistic level, modelling tools may include a toolbox of components that can be used to build models. If a network can be made to fit the toolbox then such tools can be of use. However, it is often the case that the toolbox can only accurately represent the network at its most abstract and generic level. Moving beyond such tools typically requires a bespoke definition to meet the requirements of the particular optimisation tool or system in which it is to be used.
An alternative to modelling is to use real networks or data captured from real networks. Of course, this requires that the network exists in the configuration and under the conditions needed for analysis. In many situations it does not (and even if it does, that does not imply that the network can be taken out of service or can accommodate testing in addition to its current functions).